onPressed: () {
  setState(() {
    _listData.add(textController.text);
    textController.clear();
  });
},

這段程式碼（出處請看上一篇最後一段程式碼）的意思是說「按下按鈕後，會在執行畫面更新同時並且在listData的資料列中增加一筆資料，這筆資料取自輸入匡的內容，然後清除輸入匡。」
（講個無聊的小廢話：輸入匡在輸入完資料並新增後自動清除輸入匡內容，這不是什麼理所當然自動完成的事情，這是有工程師寫指令的。也就是說這世界上其實有「不要清除輸入匡」的設計與需求，所以工程師如果處理這個如此簡單理所當然的事情時，因為你設計稿上沒寫所以他就沒這樣做，這很正常！）

注意，就程式碼上來說，它正確的意義是「按下按鈕後，更新畫面，同時執行以下程式碼。」
在程式碼中有「請執行以下程式碼」這樣的功能與邏輯，在近代的軟體設計（而不是NASA在拼火箭升空、或蘋果二號剛問世時），這樣做的目的是為了讓功能變得更複雜。

以前的電腦只能一次做一件事情。
例如「等待你輸入資料或指令」「你輸入完資料或指令後處理資料或指令」「將處理的結果顯示出來」「等待你輸入接下來的資料或指令」，這種電腦的介面很簡單，都是終端機模式。
但一個開始視窗化、有複雜介面的軟體，在UI載入記憶體後、呈現在使用者眼前時，每一個功能、每一個按鈕的程式其實都已經在主記憶體中就定位了！點擊按鈕後會發生什麼事情，電腦不會等使用者按下按鈕後才回去程式裡搜索。（雖然曾經有一度是這樣設計，但那是我沒經歷過那個時代，只是耳聞。）
所以程式設計要寫成「按鈕被按下去後要做什麼事情，我先準備好，等按鈕按下的瞬間就直接觸發，不用再來找程式。」
這種程式設計原則有很多名稱，去追那名稱追不完，知道那名稱、背好定義內容也不表示你能寫好程式。
總之只是在這裡用白話文盡可能把寫程式是怎麼回事、或技術的概念解釋給大家聽，這樣就算讀完不會想用AI寫程式，但以後跟工程師溝通可能也會「順暢」一點。

程式這樣設計的另一個用意在於「實現多線程的安全性」。
這是什麼意思？

現代的作業系統架構允許「一次執行很多程式」，但其實作業系統自己本身也是種程式，就連「桌面」也是。
也就是說「無論如何，在視窗時代，電腦一次都至少要執行作業系統與桌面這兩個程式。」（這其實不是很重要。不同的作業系統與架構，也有可能會有不同的情況？）
而怎麼顯示UI的權限通常都歸作業系統管轄。

用個很奇妙的比喻：UI就像個布偶，程式就是布偶產生器、布偶管理員、布偶劇碼的編劇，而作業系統才是真正的布偶操縱師，同時也是布偶產生器、布偶管理員、布偶劇碼編劇的調配總指揮。

介面如果要修改，例如劇本上寫著「要幫布偶加個紅帽子」，其實作業系統不會知道「紅帽子」長什麼樣，這需要回頭問布偶產生器。

但布偶產生器生出的紅帽子不能直接自己拿來套在布偶上，這樣台下觀眾就會看到一隻手忽然伸出來，必須要由布偶操縱師用自己的辦法把紅帽子加到布偶上。（當然，布偶操縱師可以偷偷把布偶收回到台下，讓布偶產生器修改布偶，修改完再拿回台上，或是請布偶產生器產生帶著紅帽子的布偶，再瞬間偷偷交換，這些都是真實存在的程式運作方式，但這些方法其實都不好，例如破壞使用體驗或佔據太多記憶體。）
這個辦法稱為權限。「在布偶演出時，只有布偶操縱師有辦法碰布偶、變化布偶，其餘人請縮在台下當工作人員接受布偶操縱師支配與呼叫，不要讓台下觀眾看到工作人員。」
所以程式（一部份）就像劇本，（還有一部份）也像個布偶，有些機車一點的作業系統連更換帽子的辦法都要程式自己負責，有些嚴厲的作業系統會在你程式提供的辦法有疏漏時給予最嚴厲的處置（殺無赦、一律強制終結）。
這些差異最終形成了「軟體設計」這個產業，程式設計就此有了硬體、軟體、韌體、前端、後端...的各種差異。

（本來很想用「男人怎麼發洩慾望：A片、買Ｘ、約P、打手C、蹲在人少的巷子裡等」做比喻，但好像太踩線了，所以...就這樣吧！）

對了！線程！

以上所說都是軟體面，是以作業系統為核心的視角。
但從硬體來說，大家都是個「線程」而已，都是個準備餵給CPU處理的一連串指令與記憶體配置。
作業系統是一或多個線程，一個線程可能用來管理其他程式，一個線程用來操縱布偶，其他程式每個都是一個線程。
但硬體的顯示功能應該要只認「操縱布偶」的線程，因為布偶就是介面。
如果硬體可以隨意聽取任意一個握有布偶的線程，（尤其是布偶產生器的線程，）那畫面會整天閃個不停。
一秒三十二楨畫面，如果有一楨的畫面讀取的布偶跟其他三十一楨不一樣，那使用者的眼睛與大腦就好玩了。

為了避免這種事情發生，所以線程被加上了權限。有些線程有權限做某些事情，有些線程沒有，有些權限可以被打開，有些權限被寫死了。

軟體業嘛～如果規則講的清晰穩定好懂，這個行業就難混了。